System and method for using a scripting language to set digital camera device features

ABSTRACT

A system and method for using scripts and selectable feature parameters to configure digital camera device features. The digital camera includes memory storing scripts for providing digital camera device features, an interface enabling a user to modify feature settings, a port connectable to a host computer for modifying or adding scripts to the memory, and a script manager for interpreting the scripts and the feature settings. The digital camera further includes an imaging device for generating a digitized image, and image processors for enhancing the digitized image according to the scripts and the selected feature settings. The digital camera still further includes command handlers for configuring the imaging device and the image processors according to the scripts and the feature settings.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application relates to co-pending U.S. patent application Ser. No.08/631,173, entitled “System and Method for Using a Unified MemoryArchitecture to Implement a Digital Camera Device,” which is herebyincorporated by reference.

BACKGROUND OF THE INVENTION

1. Field of the Invention

This invention relates generally to digital cameras and moreparticularly to a system and method for using a scripting language toset digital camera device features.

2. Description of the Background Art

A modern digital camera typically includes an imaging device and abuilt-in computer. The imaging device captures raw image informationrepresenting a scene and is controlled by the built-in computer system.The built-in computer system receives, processes and compresses the rawimage information before storing the compressed digital information inan internal memory.

A typical digital camera enables a user to manipulate mechanicalbuttons, rotatable and toggle switches, etc. to select a few of thecamera feature settings. However, the remainder of the digital camerafeatures are typically based on built-in computer system programming.Original Equipment Manufacturers (OEMs) set the software-based featuresand software-based feature settings for each digital camera.Accordingly, consumers examine both the camera hardware and the cameraprogramming to determine whether or not to purchase the camera.

Except for a few OEM selected features, the camera feature programmingis stored in Read-Only Memory (ROM). Thus, the majority of the camerafeature programming is not user accessible and thus not modifiable.Further, new features cannot be added. A system and method are neededfor enabling an ordinary user to set digital camera device featureseasily. Further, a system and method are needed for enabling aprogrammer to add digital camera device features which are also settableby the ordinary user.

SUMMARY OF THE INVENTION

In accordance with the present invention, a system and method aredisclosed for using scripts to implement digital camera features. Thedigital camera includes memory storing scripts for providing digitalcamera device features, an interface for receiving user selected featuresettings, a script manager for interpreting the scripts and the featuresettings to generate data structures, and a command handler forconfiguring the camera to provide the camera features. The digitalcamera further includes an imaging device for generating a digitizedimage and image processors for enhancing the digitized image. Since theuser need only select the camera feature script and then run andoptionally interact with the camera-configuring script, the ordinaryuser can modify the camera features.

The digital camera includes a port connectable to host computer foradding or modifying scripts to add or modify available camera features.The host computer uses a text editor application program to generate ormodify scripts, and optionally uses any error detection applicationprogram for error testing the script. The camera may be connected to thehost computer for downloading the newly-generated camera-configuringscript into camera memory. Alternately, the script can be loaded onto aremovable memory card and inserted into the camera. The added ormodified script can be run to configure the camera according to aselected feature and setting.

The invention further provides a method for generating data structuresfrom a script. The method begins by receiving a feature setting commandwhich includes a command name, a feature name and a feature setting byan interface from a user. Using a command table which includes a set ofcommand names and corresponding command codes, command codes areextracted based on the command names. Using a command parameter tablewhich includes corresponding parameter formats, the parameters areextracted based on the parameter format list. Parameters may includefeature names and settings. Accordingly, a data structure which includesthe command code and parameters, including any feature settings in thespecified format is then generated by the script manager. The datastructure is sent to a command handler for execution and generation ofresponsive data, which is sent back to the script manager forprocessing.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram illustrating a digital camera in accordancewith the present invention;

FIG. 2 is a block diagram illustrating the imaging device of FIG. 1;

FIG. 3 is a block diagram illustrating the computer of FIG. 1;

FIG. 4 is a memory map illustrating the ROM of FIG. 3;

FIG. 5 is a memory map illustrating the DRAM of FIG. 3;

FIG. 6A is a block diagram illustrating the FIG. 4 script manager;

FIG. 6B is a block diagram illustrating operations of the FIG. 1 camera;

FIG. 7A is a flowchart illustrating the preferred method for generatinga data structure from a script statement;

FIG. 7B is a flowchart illustrating the preferred method for executing acommand;

FIG. 8 is a flowchart further illustrating the step of building a datastructure of FIG. 7A;

FIG. 9 is a block diagram illustrating an external command send datastructure; and

FIG. 10 is a block diagram illustrating an external command receive datastructure.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

FIG. 1 is a block diagram of a digital camera 110 having modifiablecamera features such as exposure, focus, date/time stamp, etc., andcoupled to a host computer 120. Camera 110 comprises an imaging device114 coupled via a system bus 116 to a computer 118. When a photographerdepresses an action button (not shown), computer 118 instructs imagingdevice 114 to take a picture of an object 112. Imaging device 114optically captures and forwards light-based image informationrepresenting object 112 via system bus 116 to computer 118. Based on thecamera 110 features, computer 118 performs various image processingfunctions on the image information before storing the processed data ininternal memory (not shown). Camera 110 uses scripts, which may beauthored and error tested on host computer 120, to configure itsfeatures. A conventional text editor application program (not shown) maybe used on host computer 120 for generating a script and an errorreporter application program (not shown) may be used on host computer120 for error testing the script. If the error reporter locates anerror, then the script may be edited until the error reporter determinesthat the script will provide the intended camera 110 feature. Camera 110may be connected to host computer 120, and the script may be downloadedfrom host computer 120 into camera 110 by moving the script to a systemfolder (not shown) in camera 110 memory or to a flash disk.

FIG. 2 is a block diagram illustrating imaging device 114, whichcomprises a lens 220, a filter 222, an image sensor 224, a timinggenerator 226, an analog signal processor 228, an analog-to-digital(A/D) converter 230, an interface 232 and a motor 234. A detaileddiscussion of the preferred elements of imaging device 114 is providedin U.S. patent application Ser. No. 08/355,031, entitled “A System andMethod For Generating a Contrast Overlay as a Focus Assist for anImaging Device,” filed on Dec. 13, 1994, which is hereby incorporated byreference.

Briefly, light-based information identifying object 112 passes alongoptical path 236 through lens 220 and filter 222 to image sensor 224.Image sensor 224 captures the light data, generates light-based imageinformation from the light data, and routes the light-based imageinformation through analog signal processor 228, AID converter 230 andinterface 232. Interface 232 controls analog signal processor 228, motor234 and timing generator 226, and passes the light-based imageinformation via system bus 116 to computer 118.

FIG. 3 is a block diagram illustrating computer 118, which comprises acentral processing unit (CPU) 344, Dynamic Random-Access Memory (DRAM)346, an Input/Output (I/O) interface 348 and Read-Only Memory (ROM) 350,each connected to system bus 116. Computer 118 optionally furtherincludes a buffers/connector 352 coupled to system bus 116, and aremovable memory 354 coupled via a path 356 to buffers/connector 352.

CPU 344 controls camera 110 operations and may include a microprocessordevice such as Motorola MPC821 manufactured by Motorola, Inc. ofSchaumburg, Ill. or a Hitachi SH3 manufactured by Hitachi America, Ltd.of Terrytown, N.Y. CPU 344 optionally uses a multithreaded environmentfor concurrent activation of multiple camera 110 control functions. DRAM346 is conventional DRAM selectively allocated to various storagefunctions including image data storage. I/O interface 348 permits hostcomputer 120 or a user via externally-mounted user controls and anexternal LCD display panel to communicate with computer 118.

ROM 350 stores computer-readable program instructions for controllingcamera 110 operations. Buffers/connector 352 provides an interface, suchas a Personal Computer Memory Card International Standard (PCMCIA) slot,for connecting a removable memory. Removable memory 354 is preferably areadily removable and replaceable non-volatile data storage device suchas a flash disk, and serves as an additional image data storage area. Auser who possesses several removable memories 354 may replace a fullremovable memory 354 with an empty removable memory 354 to effectivelyexpand the picture-taking capacity of camera 110.

FIG. 4 is a memory map illustrating ROM 350, which stores programsincluding a control application 400, a toolbox 402, drivers 404, akernel 406 and a system configuration 408. Control application 400comprises program instructions for managing the various camera 110functions and executing script commands. Toolbox 402 comprises selectedfunction modules including a script manager 410, external commandhandlers 420, image processors 430 and camera control system 440. Scriptmanager 410 operates as a script interpreter by generating datastructures from script statements which are used to provide the camera110 features. External command handlers 420 manage the data structuresgenerated by script manager 410 and may store parameter values in aprogrammable RAM (PRAM) such as an EEPROM. Image processors 430 areprograms for enhancing (e.g., adjusting the contrast, sharpening,converting the image to gray-scale, etc.) the digital image receivedfrom imaging device 114. Camera control system 440 receives andprocesses the data structures from the external command handlers 420 forcontrolling camera functions. System functions, I/O functions, camerahardware functions, image processor functions are controlled by thecontrol application and toolbox routines receiving data structures fromexternal command handlers. Script manager 410 operations are describedin greater detail with reference to FIG. 6.

Drivers 404 comprise program instructions for controlling various camera110 hardware components, such as motor 234 (FIG. 2) and a flash (notshown). Kernel 406 comprises program instructions providing basicunderlying camera 110 services including synchronization routines, taskcreation, activation and deactivation routines, resource managementroutines, etc. System configuration 408 comprises program instructionsfor providing initial camera 110 start-up routines such as the systemboot routine and system diagnostics.

FIG. 5 is a memory map illustrating DRAM 346, which includes a workingmemory 530, a RAM disk 532 and a system area 534. Working memory 530stores camera-configuring scripts 536. Scripts 536 comprise programstatements which may include commands, which are loaded at start-up bythe configuration software from the RAM disk or flash disk. A command isa function routine call comprising a command name, optionally a sendlist and optionally a receive list. An example of a command is“GetCameraStates (1,‘hint’:3?,hint)” where “GetCameraStates” is thecommand name, “1,‘hint’” is the send list, “:” separates the send listfrom the receive list, and “3?,hint” is the receive list. The commandname GetCameraStates calls the function routine for retrieving thestatus value of a particular feature. The “1” in the send list indicatesthat only one request is being made. The “‘hint’” indicates that thevalue requested is for the hint feature. The “3?” in the receive listindicates that upon receipt of responsive data three values should beskipped, and the “hint” in the receive list specifics the variable inwhich to store the fourth value. Combining both the send list and thereceive list in the command provides a simple command structure.

A script for configuring the camera hint mode, which enables the camerato select exposure type automatically (AUTO), to set exposure such thatthe background is out of focus (PORT), to set the exposure to capture asmuch depth of field as possible (LAND), to shift exposure to provide afast shutter speed for moving objects (SPRT) or to maximize depth offield for objects in very close proximity (CLOS), is as follows:

#HINT_01 CSM (1) name “Set Exposure Hint Mode” (2) declare u:hint (3)GetCameraStates(1,“hint” 3?,hint) (4) get hint (5)  1: “AUTO”  2: “PORT” 3: “LAND”  4: “SPRT”  5: “CLOS” end (6)SetCameraStates(false,1,“hint”,hint) (7) SetScriptStatus(1,“hint”) (8)Script manager 410 enables execution and re-execution of the script formodifying and re-modifying the hint mode setting. At any time, a usercan instruct script manager 410 to execute the exposure hint featurescript for setting or resetting the hint feature.

Statement (1) is a comment identifying the DOS name of the script.Statement (2) specifics the script description to be provided upon userrequest. Statement (3) defines a variable “hint” as an unsigned integeru. A variable type table is shown below in table 1.

TABLE 1 Variable Types Specifier Description u 32 bits unsigned integer.i 32 bits signed integer. f 32 bits signed fractional port in signed 15bits signed integer and 16 bits fraction s 32 bytes characterscontaining a string up to 31 significant characters terminated by a nullcharacter. n 16 bytes string contains DOS filename, format as (8characters). (3 characters) or (8 characters). p 4 characters string. b32 bits of Boolean flags, each bit can be either true(1) or false(0) lidentifier used to indicate a label nameStatement (4) is a command for retrieving the previously set value ofhint. Statement (5) is a user interaction statement which comprises acommand requesting that the user accept or modify the hint mode setting.The list of values and strings separated by colons is the feature valuerelated to the string name for that feature. The user selects a featureby name, and the selected name's value is returned in the variable.Statement (6) ends the list in statement (5). Statement (7) instructscontrol application 400 to reconfigure the hint mode as the userselects. Lastly, statement (8) communicates modifications to the uservia the optional LCD status display.

RAM disk 532 is a RAM-based data storage area for storing the compressedlight-based image information and is typically organized in a sectoredformat similar to that of conventional hard disk drives. RAM disk 532may use a standardized file system enabling the external host computersystem (not shown) to readily access stored data. Because theinformation is actually stored in RAM, the data can be easily andquickly retrieved. System area 534 typically stores system errorinformation for CPU 344 to report upon restarting computer 118 after asystem error occurs.

FIG. 6A is a block diagram illustrating script manager 410 whichincludes a function decoder 605, function handlers 610, a tokenizer 620,a command interpreter 625, internal command handlers 630, a programmingstatement interpreter 635, a command table 640 and a variable table 645.

Function decoder 605 is a program routine for managing and decodingscript messages received from control application 400. Function decoder605 forwards the decoded script messages to function handlers 610, whichare program routines for managing these messages. If the script messageonly includes simple instructions (i.e., instruction such as initialize,abort, search for, GetName and Reset which do not require scriptexecution), then function handlers 610 perform the required functionsand return the appropriate responses via function decoder 605 back tocontrol application 400. If the script message includes a complexinstruction, (i.e., an instruction such as GetCameraStates orSetCameraStates which requires script execution and interpretation),then function handlers 610 forward the message to tokenizer 620 forcomplex instruction handling.

Tokenizer 620 examines the syntax of the statements in the scriptmessage to convert the statement's ASCII codes into tokens. Tokenizer620 passes tokens corresponding to script commands to commandinterpreters 625 and tokens corresponding to Arithmetic Logic Unit (ALU)statements, Input/Output (I/O) statements, control statements anddocumentation statements to programming statement interpreter 635.

Command interpreters 625 generate data structures representing thetokens. Command interpreters 625 forward the data structures forexternal commands (i.e., commands which are used system-wide such asGetCameraStates or SetCameraStates and which require computations orinformation exchange with external components) to external commandhandlers 420, by passing them back as a response via the functiondecoder 605. The control application then passes the response to theappropriate external command handler 420 for processing based on thecommand code. Command interpreters 625 pass data structures for internalscript commands (i.e., commands which are dedicated to script manager410 such as Wait, Write, GetTimeString or GetDateString) are passed tointernal command handler 630.

To indicate whether a command is an internal command or an externalcommand, each command entry in the command table may include anexternal/internal flag, command interpreter 625 may include anexternal/internal command table, or the command values may indicateaccordingly. To create a data structure from a script command, commandinterpreters 625 use command table 640 and variable table 645. Anexample command table 640 is shown in table 2.

TABLE 2 Command Table Command Command Parameter Parameter Name CodeCount Type List “GetCameraStates” 0 ± 0005 2 1, 16, 0, 0, 0, 0“GetCameraCapabilities” 0 ± 0006 2 1, 16, 0, 0, 0, 0 “SetCameraStates” 0± 0007 3 4, 1, 17, 0, 0, 0 “GetCameraStatus” 0 ± 0008 0 0, 0, 0, 0, 0, 0The first column indicates command names, the second column indicatescommand codes, third column indicates the number of parameters in theparameter type send lists, and the fourth column indicates parametertype send list formats. It will be appreciated that other commands andother parameter type lists may be included in command table 2.

In conjunction with the parameter type list of command table 2, commandinterpreters 625 use a parameter type table 3 as follows:

TABLE 3 Parameter Type Table Parameter Value Description cuInteger (1)integer between 0 and 4G, 32 bit unsigned integer, a preceding 0x or 0xmeans hex value, otherwise decimal value. cInteger (2) integer between−2G and +2G, 32 bit signed integer, a preceding 0x or 0x means hexvalue, otherwise decimal value. cFixed (3) fixed integer between−32767.99999 . . . and +32767.99999 . . . , 32 bit signed fractionalpart in signed 15-bit signed integer and 16-bit fraction. cBitFlags (4)Boolean and bitflags; 32 bits of Boolean flags, each bit can be eithertrue(1) or false(0), “0b” means Boolean, “0x” or “0x” means hex,otherwise decimal value cPName (6) parameter name. cName (7) DOSfilename: 16 byte string surrounded by double quotes. The format is anup to 8 character filename, followed by a period, and a up to threecharacter extension or up to 8 character filename; example“myscript.csm.” cString (8) a sequence of characters surrounded bydouble quotes, max. length is 31, no double quotes inside the characterstring. cPList (16)  parameter list. cPVList (17)  parameter/value list.cNameList (18)  DOS filename list. cUList (19)  unsigned integer listFor example, the command “GetCameraCapabilities” parameter list “1,16”specifies that the send list must contain a cUInteger, which is definedas a 32 bit unsigned integer between 0 and 4 G, followed by a cPListwhich is defined as a parameter list. A cPList is simply a list of anylength of pName type values. Command interpreters 625 use tables 2 and 3to compare predefined script formats with actual scripts for performingscript command error checking. Error checking is defined in greaterdetail with reference to FIGS. 7 and 8. Generation of a data structureby command interpreters 625 is described in detail with reference toFIGS. 7-10.

An example variable (or parameter) table is illustrated in table 4 asfollows:

TABLE 4 Variable Table Variable Name Type Value “count” 1 0 “valu” 31.25

External and internal command handlers 420 and 650 accordingly sendimage processor parameters to image processors 430 for setting camera110 software-based features, or camera parameters to the camera controlsystem 440 for setting capture-related features. Although not shown,command handlers 420/650 may send I/O parameters to I/O interface 348for setting I/O features or other system or control parameters to othermanagers for setting other camera 110 features. The operations ofexternal command handlers 420 and internal command handlers 630 aredescribed below in greater detail with reference to FIG. 7B.

Programming statement interpreter 635 uses variable table 645 to processa programming statement such as control, I/O, ALU or documentationstatements. For example, a programming statement may be a definition, amathematical expression, a logical expression, etc.

If one of the script manager 410 components including the tokenizer 620,the command interpreters 625, the programming statement interpreter 635,the internal command handler 630 locates an error in the script message,then the script manager 410 component sends an error message to an errorhandler 615 of function handlers 610. The error handler 615 recognizeserror codes in the error message, stops script execution and passes anappropriate error message responsively back via function decoder 605 toI/O interface 348.

FIG. 6B is a block diagram illustrating the operations of camera 100.Imaging device 114 captures and converts an image to a digitized image,and stores the digitized image in memory 354. Image processor 430 takesthe raw digitized image and adds image enhancements such as contrastadjustment, sharpening, etc. Image processor 430 stores the enhancedimage again in memory 354.

The operations of imaging device 114 and of image processors 430 can becontrolled by active scripts and script feature settings. Whileexecuting a script, the script manager 410 retrieves and displays thescript feature setting currently-stored in the script data base 536 forthe selected script. The script manager 410 can interact with a user viaI/O interface 348 to enable modification or the currently-stored scriptfeature setting in order to modify the camera device feature. Scriptmanager 410 generates data structures representing commands within thescript, as described below with reference to FIGS. 7A and 8-10.

Script manager 410 sends the data structures to external/internalcommand handlers 420/650, which accordingly send image processorparameters to image processors 430 for setting camera 110 software-basedfeatures, camera parameters to camera control software for settingcapture features, or other system or control parameters to otherappropriate managers. It will be appreciated that a programmer may usehost computer 120 to add additional scripts to script data base 536, foradding additional functions and features to camera 110.

FIG. 7A is a flowchart illustrating a method 700 for managing script 536statements. Method 700 begins in step 702 by tokenizer 620 receiving andparsing a statement. If tokenizer 620 in step 704 determines that theprogram statement is not a script command, then tokenizer 620 sends thetokens to programming statement interpreters 635, which in step 706analyze the statement. Programming statement interpreter 635 in step 708executes the program statement conventionally. Examples of thesestatements include control, I/O, ALU and documentation statements.Tokenizer 620 in step 710 determines whether there is another statementin script 536. If so, then tokenizer 620 returns to step 702. Otherwise,method 700 ends.

If tokenizer 620 in step 704 determines that the program statement is ascript command, then tokenizer 620 sends the token to commandinterpreters 625 which in step 712 retrieve the command code and theparameter list from the command table 640 illustrated above in Table 2described with reference to FIG. 6. Using the command code and theparameter list, command interpreters 625 in step 714 scan the parametersand build a data structure. The step of building a data structure from acommand is described in detail with reference to FIG. 8.

Command interpreters 625 in step 716 forward data structuresrepresenting external commands via a response through the functiondecoder 605 back to the control application 400 to external commandhandler 420 or data structures representing internal commands tointernal command handlers 630 for command execution. Command executionis described below with reference to FIG. 7B.

Command interpreters 625 in step 718 receive responsive data returnedfrom command handlers 420 or 650. Command interpreters 625 in step 719examine the data returned to determine if the data indicates an error.If so, then command interpreters 726 jump to step 726 to report theerror. Otherwise, command interpreters 625 continue with step 720 todetermine whether the current command includes a receive list. If not,then method 700 returns to step 710. If so, then command interpreters625 in step 722 examine the expected parameter type in the receive list.

If the expected parameter type is a constant, then command interpreters625 determine whether the responsive data matches the expected parametertype. If not, then command interpreters 625 inform the error handler615, which in step 726 reports the error and method 700 then ends.Otherwise, command interpreters 625 in step 728 advance four bytes foran integer value, sixteen bytes for a DOS name or thirty-two bytes for acharacter string to index to the next parameter. Command interpreters625 in step 730 determine whether another parameter remains in thereceive list. If so, then command interpreters 625 return to step 722.Otherwise, command interpreters 625 return to step 710.

If command interpreters 625 in step 722 determine that the parametertype is a variable, then command interpreters 625 in step 731 determineif the variable has been defined. If not, then method 700 jumps to step726 to report the error. Otherwise, command interpreters 625 in step 732stuff the received data value into the variable and proceed to step 728to index to the next parameter.

If command interpreters 625 in step 728 determine that the parametertype is a number N followed by the symbol “?”, then command interpreters625 in step 734 extract the value N. Command interpreters 625 in step736 index past N×4 bytes of responsive data, i.e. N parameters. The type“N?” is used to index past parameters which are known to be unnecessaryfor performing the current instruction. For example, the command“GetCameraStates(1, ‘fmod’:3?, abc)” requests the current state ofcamera 110 focus mode. The responsive data may be “1,‘fmod’,1,25” where“25 represents the current focus mode state. Parameter “3?” causescommand interpreters 625 to jump over the first three parameters“1,‘fmod’,1”, and on the next loop stuff the value “25” into thevariable “abc.” Thus, the function “N?” eliminates examination ofparameters known to be unnecessary. Command interpreters 625 thenproceed to step 734.

FIG. 7B is a flowchart illustrating details of the method 716 forexecuting a command. Method 716 begins with step 740 by commandinterpreters 625 determining whether the command is an external commandor an internal command. If the command is an external command, thencommand interpreters 625 in step 742 sends the data structure (whichrepresents the command and the send list) and the response code tofunction decoder 605, which decodes and forwards the data structure andresponse code to control application 400. Control application 400 instep 744 sends the data structures to the appropriate external commandhandler 420. The appropriate external command handler 420 in step 746executes the command data structure and in step 748 forwards theappropriate response data back to the control application, which in turncalls the script manager 410 with the result. The function decoder 605sends the response data back to command interpreters 625. Method 716then ends.

If in step 740 command interpreters 625 determine that the command is aninternal command, then command interpreters 625 in step 750 sends thedata structure (which represents the command and the send list) to theappropriate internal command handler 630. Method 716 then jumps to step746.

FIG. 8 further illustrates step 714 of building a data structure. Step714 begins in step 805 by command interpreters 625 creating a commanddata structure header. Command interpreters 625 in step 810 get the nextparameter and in step 815 determine the parameter type. Commandinterpreters 625 in step 820 determine if the parameter matches theexpected parameter type. For example, by examining table 2 and table 3,command interpreters 625 expect the command “GetCameraStates” to befollowed by a send list comprising a cUInteger (1) in turn followed by acPList (16). If the selected parameter is not a member of the expectedparameter type, then command interpreters 625 forward a message to errorhandler 615, which in step 825 reports the error via a response throughthe function decoder 605 to the control application 400. The controlapplication reports the error to the user. As illustrated by jump symbol“A,” method 700 then ends.

If the selected parameter is a member of the expected parameter type,then command interpreters 625 in step 830 determine whether theparameter is a constant or a variable. If the parameter is a variable,then command interpreters 625 in step 833 determine if the variable isdefined. If not, then method 714 jumps to step 726 (FIG. 7A) to reportthe error. Otherwise, command interpreters 625 in step 835 retrieve thevalue of the variable. If the parameter is a constant, then commandinterpreters 625 convert the ASCII constant to a value. In either case,command interpreters 625 in step 845 append the value to the send datastructure. Command interpreters 625 in step 850 increment the datastructure size in the header by 4, 8 or 16 bytes depending on the datatype. Command interpreters 625 in step 855 determine if the retrievedparameter is the last parameter. If so, then method 714 ends. If not,then method 714 returns to step 810.

FIG. 9 is a block diagram illustrating a command send data structure900, which comprises a header 905 and appended parameters 930, generatedby command interpreters 625. Header 905 comprises a command code 910, acommand data length 915, a command data pointer 920 and a deallocationroutine pointer 925. Parameters 930 may include a plurality of appendedparameters 935-945.

For the example command “GetCameraStates(1, ‘fmod’:3?,fmod)”, commandinterpreters 625 retrieve the command code “0×0005” for“GetCameraStates” as command code 910, set command data length 915 tozero and place the value nil into command data pointer 920. Commandinterpreters 625 append an address of the subroutine which will disposeof the data structure as a deallocation routine pointer 925. Commandinterpreters 625 retrieve the parameter “1” and determine that itmatches the expected parameter type cUInteger. Since the parameter is aconstant, command interpreters 625 append the 32-bit parameter valuerepresenting “1” to the data structure as parameter #1 data 935. Commandinterpreters 625 modify command data pointer 920 to point to parameter#1 data 935, and increment command data length 915 by four bytes.Command interpreters 625 retrieve the parameter “fmod” and determinethat it matches the expected parameter type cPList. Since the parametertype is a parameter name constant, external command interpreters 625append the constant “fmod” to send data structure 900 as parameter #2data 940. Command interpreters 625 increment command data length 915 byanother four bytes. In this example, there are only two parameters andcommand data length is eight bytes.

FIG. 10 is a block diagram illustrating a command retrieve datastructure 1000, which comprises a header 1005 and return parameters1030. Header 1005 comprises a command error code 1010, a command datalength 1015, a command data pointer 1020 and a deallocation routinepointer 1025. Return parameters 1030 may include parameter #1 data 1035and parameter #2 data 1040. Any number of parameters may be included.

As described in FIG. 7A, command interpreters 625 receive the commandreceive data structure 1000 as responsive data returned from eitherexternal command handlers 420 or internal command handlers 630. Commandinterpreters 625 process the receive list “3?,fmod” with the datastructure 1030 values.

The foregoing description of the preferred embodiments of the inventionis by way of example only, and other variations of the above-describedembodiments and methods are provided by the present invention.Components of this invention may be implemented using a programmedgeneral purpose digital computer, using application specific integratedcircuits, or using a network of interconnected conventional componentsand circuits. The embodiments described herein have been presented forpurposes of illustration and are not intended to be exhaustive orlimiting. Many variations and modifications are possible in light of theforegoing teaching. The system is limited only by the following claims:

1. A digital camera system comprising: an imaging device for receivingpicture data; script memory coupled to the imaging device for storingcamera-configuring scripts; an interface coupled to the script memoryfor enabling the selection of a script feature setting; a scriptmanager, coupled to the interface for interpreting the script and thescript feature setting, and including a command interpreter coupled tothe script memory, a programming statement interpreter coupled to thescript memory, and a tokenizer for determining when to send aninstruction to the command interpreter and when to send an instructionto the programming statement interpreter; a command handler coupled tothe script manager for processing the script based on the script featuresetting to provide a camera feature; control application memory coupledto the imaging device for controlling the camera features based oncamera parameters; and an image processor coupled to the command handlerfor controlling a processing of the picture data based on the scriptfeature setting.
 2. The system of claim 1, wherein the command handlerincludes an external command handler coupled to the script manager forprocessing external commands; and an internal command handler coupled tothe script manager for processing internal commands.
 3. A digital camerasystem comprising: an imaging device for receiving picture data; scriptmemory coupled to the imaging device for storing camera-configuringscripts and a command; an interface coupled to the script memory forenabling the selection of a script feature setting; a script managercoupled to the interface for interpreting the script and the scriptfeature setting, and including an error handler for providing an errorreport to the interface upon indication of an error in the script, andfurther including a command table for interpreting the command, and acommand handler coupled to the script manager for processing the scriptbased on the script feature setting to provide a camera feature.
 4. Thesystem of claim 3, further comprising a communications port coupled tothe script memory for transferring different scripts from an externalhost computer to the script memory.
 5. A digital camera system,comprising: means for receiving picture data; script means, coupled tothe means for receiving, for storing a camera-configuring script;interface means, coupled to the script means, for enabling selection ofa script feature setting; interpretation means, coupled to the interfacemeans, for interpreting the script and the script feature setting, andincluding a command interpreter means coupled to the means forreceiving, a programming statement interpreter means coupled to themeans for receiving; and a tokenizer for determining when to send aninstruction to the command interpreter means and when to send aninstruction to the programming statement interpreter means; commandhandler means, coupled to the interpretation means, for processing thescript based on the script feature setting to provide a camera feature;control means, coupled to the means for receiving, for controlling thecamera features based on camera parameters; and image processor means,coupled to the command handler means, for controlling a processing ofthe picture data based on the script feature setting.
 6. The system ofclaim 5, wherein the command handler means includes: external commandhandler means coupled to the interpretation means for processingexternal commands; and internal command handler means coupled to theinterpretation means for processing internal commands.
 7. A system forusing parameter tables to generate a data structure for setting digitalcamera device features, comprising: means for receiving including an I/Ointerface for receiving a camera feature setting command which includesa command name, a feature name and a feature setting from a user; acommand table, coupled to the means for receiving, including commandnames and corresponding command codes; a feature table, coupled to themeans for receiving, including features, corresponding feature codes,corresponding available feature settings and corresponding featuresetting codes; an interpreter, coupled to the means for receiving, forusing the command table and the feature table to generate a datastructure having the command code representing the command, the featurecode representing the feature and the feature setting code representingthe feature setting; and a command handler, coupled to the interpreter,for processing data structures.
 8. A system for using parameter tablesto generate a data structure for setting digital camera device features,comprising: means for receiving a camera feature setting command whichincludes a command name, a feature name and a feature setting; a commandtable, coupled to the means for receiving, including command names andcorresponding command codes: a feature table, coupled to the means forreceiving, including features, corresponding feature codes,corresponding available feature settings and corresponding featuresetting codes; an interpreter, coupled to the means for receiving, forusing the command table and the feature table to generate a datastructure having the command code representing the command, the featurecode representing the feature and the feature setting code representingthe feature setting; and an error handler, coupled to the interpreter,for providing an error report upon indication of an error.
 9. A methodof using parameter tables to generate a data structure for settingdigital camera device features, comprising the steps of: receiving, byan interface, a feature setting command which includes a command name, afeature name and a feature setting; using, by a script manager, acommand table which includes a set of command names and correspondingcommand codes to extract command codes based on the command names;using, by the script manager, a feature table which includes a pluralityof feature sets, each set including a feature name, a correspondingfeature code, corresponding available feature settings and correspondingfeature setting code, to extract the corresponding feature code andcorresponding feature setting code based on the received feature nameand the received feature setting; generating, by the script manager, amessage packet which includes the command code, the feature code and thefeature setting code; and providing an error report upon indication ofan error to the interface.
 10. The method of claim 9, furthercomprising, after generating, the step of using a control application tomodify camera parameters for setting camera device features.
 11. Amethod of using parameter tables to generate a data structure forsetting digital camera device features, comprising the steps of:receiving, by an interface, a feature setting command which includes acommand name, a feature name and a feature setting; using, by a scriptmanager, a command table which includes a set of command names andcorresponding command codes to extract command codes based on thecommand names; using, by the script manager, a feature table whichincludes a plurality of feature sets, each set including a feature name,a corresponding feature code, corresponding available feature settingsand corresponding feature setting code, to extract the correspondingfeature code and corresponding feature setting code based on thereceived feature name and the received feature setting; generating, bythe script manager, a data structure which includes the command code,the feature code and the feature setting code; forwarding, by the scriptmanager, the data structure to a command handler for processing the datastructure; and sending, by the command handler, responsive data in apredetermined format back to the script manager.
 12. The method of claim11, further comprising ignoring, by the script manager, a portion of theresponsive data based on a flag in the command.
 13. A digital camera,comprising: a script memory for storing a camera-configuring script; ascript manager coupled to the script memory for generating datastructures, representing commands within the script, wherein the scriptmanager includes a tokenizer for determining when to send an instructionto a command interpreter and when to send an instruction to aprogramming statement interpreter; and a command handler coupled to thescript manager for selectively executing the commands represented by thedata structures according to the script to provide a digital camerafeature.
 14. The digital camera of claim 13, further including aninterface coupled to the script manager for enabling the selection of ascript feature setting, wherein the command handler processes the scriptbased on the script feature setting.
 15. The digital camera of claim 13,wherein the command handler provides image processing parameters to animage processor in the digital camera for processing digital image data.16. The digital camera of claim 13, wherein the command handler providescamera parameters to an imaging device in the digital camera forcapturing digital image data.
 17. The digital camera of claim 13,wherein the script memory is coupled to a host computer for receivingscripts.
 18. A method of configuring a digital camera using a script,comprising: storing the script; generating data structures, representingcommands within the script; determining, by a tokenizer, when to send aninstruction to a command interpreter and when to send an instruction toa programming statement interpreter; and selectively executing thecommands represented by the data structures for configuring the digitalcamera according to the script.
 19. The method of claim 18 furthercomprising selecting a script feature setting for configuring thedigital camera according to the script and the script feature setting.20. A computer-readable medium coupled to a digital camera storing ascript, wherein the digital camera comprises: a script manager includinga tokenizer to: generate data structures, representing commands withinthe script; determine when to send an instruction to a commandinterpreter and when to send an instruction to a programming statementinterpreter; and a command handler to selectively execute the commandsrepresented by the data structures for configuring the digital cameraaccording to the script.